.\" Copyright (c) 1983 Regents of the University of California.
.\" All rights reserved.  The Berkeley software License Agreement
.\" specifies the terms and conditions for redistribution.
.\"
.\"	@(#)imp.4	6.2 (Berkeley) 8/2/87
.\"
.TH IMP 4 "August 2, 1987"
.UC 2
.SH NAME
imp \- 1822 network interface
.SH SYNOPSIS
.ft B
.nf
/sys/conf/SYSTEM:
	NIMP	\fIcount\fP	# ARPAnet IMP 1822 interface
.fi
.ft R
.SH DESCRIPTION
The 
.I imp
interface, as described in BBN Report 1822, provides access to an
intelligent message processor normally used when participating
in the Department of Defense ARPA network.  The network interface
communicates through a device controller, usually an ACC LH/DH or HDH
or a DEC IMP-11A, with the IMP.  The interface is \*(lqreliable\*(rq and
\*(lqflow-controlled\*(rq by the host-IMP protocol.
.PP
To configure IMP support, at least one of 
.IR acc (4),
.IR css (4)
or
.IR hdh (4)
must be included.
The
.I count
specifies the total number of IMP connections.
The network number on which the interface resides is specified
at boot time using the SIOCSIFADDR ioctl.  The host number is
discovered through receipt of NOOP messages from the IMP.
.PP
The network interface is always in one of four states: up, down,
initializing, or going down.  When the system is
booted, the interface is marked down.  If the hardware controller
is successfully probed, the interface enters the initializing
state and transmits three NOOP messages to the IMP.  It then waits
for the IMP to respond with two or more NOOP messages in reply.
When it receives these messages it enters the up state.  The ``going
down'' state is entered only when notified by the IMP of an impending
shutdown.  Packets may be sent through the interface only while it
is in the up state.  Outgoing packets are dropped
with the error ENETDOWN returned to the caller if the interface
is in any other state.
.SH DIAGNOSTICS
\fBimp%d: not configured\fP.
A hardware interface could not be attached during autoconfiguration
because too few IMP pseudo-devices were configured.
.PP
\fBimp%d: leader error\fP.  The IMP reported an error in a leader
(1822 message header).  This causes the interface to be reset and
any packets queued up for transmission to be purged.
.PP
\fBimp%d: going down in 30 seconds\fP.
.br
\fBimp%d: going down for hardware PM\fP.
.br
\fBimp%d: going down for reload software\fP.
.br
\fBimp%d: going down for emergency reset\fP.
The Network Control Center (NCC) is manipulating the IMP.  By convention
these messages are reported to all hosts on an IMP.
.PP
\fBimp?: host %x, lost %d rfnms\fP.
The IMP had messages outstanding to the host listed,
but no RFNM (Request for Next Message) messages were received from the IMP
in 127 seconds.
The software state for that host is reinitialized.
.PP
\fBimp%d: interface reset\fP.  The host has received an
interface reset message from the IMP.
.PP
\fBimp%d: address reset to x%x (%d/%d)\fP.  The host has received a
NOOP message which caused it to reset its notion of its
current address.
The Internet address is printed in hexadecimal, with the host and IMP
numbers following.
This indicates that the address originally set by
.IR ifconfig (8)
was incorrect, that the IMP has undergone an identity crisis,
or that communication between the IMP and the host is being garbled.
.PP
\fBimp%d: data error\fP.  The IMP noted an error in data
transmitted.  The host-IMP interface is reset and the host
enters the init state (awaiting NOOP messages).
.PP
\fBimp%d: interface reset\fP.  The reset process has been
completed.
.PP
\fBimp%d: marked down\fP.  After receiving a \*(lqgoing down in
30 seconds\*(rq message, and waiting 30 seconds, the host has
marked the IMP unavailable.  Before packets may be sent to the
IMP again, the IMP must notify the host, through a series of
NOOP messages, that it is back up.
.PP
\fBimp%d: can't handle af%d\fP.  The interface was handed
a message with addresses formatting in an unsuitable address
family; the packet was dropped.
.SH SEE ALSO
intro(4N),
inet(4F),
acc(4),
css(4),
hdh(4),
implog(8),
implogd(8)
